1. Field of the Invention
The invention relates to compression of streams of rendering commands.
2. Related Art
In some applications of computing devices, it is desirable to present a visualization of a scene to a user. Some of these applications include the following:                CAD (computer aided design);        computer aided search, such as used in the oil and gas industry;        computer simulations, such as battlefield simulations and flight simulation; and        video games, including multiplayer video games.        
One problem in the known art is that computing the scene to be presented requires relatively large resources, including both computing power and memory.
Known solutions include breaking up computing the scene into parts, and assigning each of those parts to a separate graphics processor. These separate graphics processors each operate under control of a single controlling processor, which determines how to break up computing the scene into parts. The controlling processor sends each separate graphics processor a set of commands telling the receiver what to render. Each graphics processor generates data showing how to render its part of the scene. This data might be sent back to the controlling processor for presentation, or might be sent on to a presenting device, such as a graphics compositor, a monitor, or a set of monitors.
While this method generally achieves the goal of providing increased resources to render the scene, it still has several drawbacks. One drawback is that it might take different amounts of time to send rendering commands to distinct graphics processors. For example, if one of the graphics processors is assigned more objects to render than others, that one graphics processor will receive a relatively larger set of rendering commands. Known systems generally provide for presenting all the rendering results at the same time. This has the effect that all graphics processors receive their rendering commands, and render their objects, before their new results can be presented.
Known systems sometimes account for the difference in completion time by double (or multiple) buffering of frames to be presented. That is, there is a frame that is currently being presented to the user, and one or more “hidden” frames being written to by the graphics processors as they render their objects. The “frame rate”, that is, the rate at which frames can be generated is limited by the rate at which the hidden frames can be updated by the graphics processors. This has the effect that the rate at which frames (of a changing scene, such as a motion picture) can be generated is limited by the longest amount of time it takes to send rendering commands to one of the graphics processors.
A second known problem in the art is mapping a complex surface onto 3D geometry.
A known solution for mapping a complex surface (aka a texture) onto 3D geometry is for the controlling device to send the texture to the rendering device(s) every time the rendering device(s) need the texture, however, this takes a significant amount of time and slows down the rendering process.
A third known problem is providing an efficient method for storing and converting vertex calls into vertex arrays.
A known solution is found in modern 3D languages or SDK's (Software Development Kits) that provide efficient ways to store large amounts of vertices in Arrays (Vertex Arrays), however, 3D applications often use individual vertex calls which is inefficient (i.e. it takes long time) due to their large size compared to vertex arrays.
Accordingly, it would be advantageous to provide methods and systems in which 3D scenes might be rapidly rendered, and which are not subject to drawbacks of the known art.